In general, a server may be configured to provide information to one or more clients according to a client/server model of information delivery. In this model, the server is a storage system that typically contains one or more mass storage devices, such as magnetic hard disks, in which information may be stored and retrieved as desired. The server is usually deployed over a computer network comprising a geographically distributed collection of interconnected communication links, such as Ethernet, optical or wireless links, that allow the clients to remotely access the server's stored information. The clients may include network devices or computers that are directly or indirectly attached to the server, e.g., via point-to-point links, shared local area networks (LAN), wide area networks (WAN) or virtual private networks (VPN) implemented over a public network such as the Internet.
In some client/server arrangements, the server may be configured as a network cache that buffers previously-accessed or frequently-accessed client information. As such, the server provides a set of clients with faster access to the buffered information than if they were to access the same information directly from the origin servers that normally serve the information. For instance, the set of clients may be physically situated closer to the network cache than to the origin servers, or the clients may be able to access the cache over a lower latency (or higher bandwidth) data path, etc. The network cache's buffered information is typically in the form of files which are made accessible to the set of clients.
In practice, the network cache can be configured to operate as a “reverse proxy” or “forward proxy” cache. A reverse-proxy cache is a server that stores a selected set of information from one or more origin servers. For example, a multimedia company may copy selected streaming audio or video content from its origin servers to a reverse-proxy cache, which is then used as an “accelerator” for providing the selected content to clients. In contrast, a forward-proxy cache is a server that buffers network data for a particular set of clients. Unlike the reverse-proxy cache, the forward-proxy cache does not necessarily store selected data from specific origin servers and instead may store data from a variety of different origin servers, i.e., based on the network traffic patterns of the cache's particular set of clients.
A reverse-proxy or forward-proxy cache may be coupled to one or more other servers in a computer network. In a conventional two-level cache hierarchy, clients communicate with “child” network caches, which are coupled to one or more higher-level “parent” caches, which in turn are coupled to one or more origin servers. A subset of the parent caches' files are stored in the child caches, and a subset of the origin servers' files are stored at the parent caches. The above-noted hierarchy may be generalized to various levels wherein each cache in the hierarchy is coupled to one or more higher-level proxy caches and/or origin servers. Network caches in such a hierarchical arrangement typically communicate with one another by exchanging discrete packets of data formatted according to predefined file-access protocols, such as the HyperText Transfer Protocol (HTTP), Network File System (NFS) protocol, Common Internet File System (CIFS) protocol, File Transfer Protocol (FTP), etc.
A network cache also may be coupled to other types of servers besides origin servers and higher-level proxy caches. For instance, the cache may be coupled to an authentication server, such as Remote Authentication Dial In User Service (RADIUS) server, that implements a predetermined authentication procedure. RADIUS and its associated protocol are generally described in more detail in the Request For Comments (RFC) 2138 entitled Remote Authentication Dial In User Service (RADIUS), by Rigney et al., published April 1997, which publication is available through the Internet Engineering Task Force (IETF) and is hereby incorporated by reference as though fully set forth herein.
Yet other types of servers also may be coupled to the network cache. For instance, Lightweight Directory Access Protocol (LDAP) servers may provide directory services for the network cache, such as storing public-key certificates, email addresses, etc., whereas Internet Content Adaptation Protocol (ICAP) servers may provide object-based content vectoring services, such as virus scanning, content filtering and the like. The LDAP protocol is generally described in more detail in RFC 2251 entitled Light-weight Directory Access Protocol (v3), by Wahl et al., published December 1997, and the ICAP protocol is described more in detail in RFC 3507 entitled Internet Content Adaptation Protocol (ICAP), by Elson et al., published April 2003, and both of these publications are hereby incorporated by reference as though fully set forth herein.
Because the network cache can communicate with servers using many different types of network communication protocols, the cache generally executes a separate protocol-specific software module for each protocol type. As used herein, a software module may be a user-level or kernel-level process or thread. For example, each protocol-specific software module may be implemented as a kernel-level protocol engine that executes in the network cache. That is, the cache may include a HTTP protocol engine that is configured to communicate with higher-level proxy caches or origin servers using the HTTP protocol. Similarly, the cache may include RADIUS, LDAP and ICAP protocol engines that respectively communicate with remote RADIUS, LDAP, and ICAP servers.
Often, the network cache may be coupled to more than one server configured to communicate using the same network communication protocol. Each protocol engine in the network cache typically includes a mechanism for selecting an optimal, or “best available,” server among multiple servers of the same protocol type. A protocol engine may select the optimal server based on various statistics associated with the servers, such as their available bandwidths, round-trip times or response times, and so forth. For example, if the cache is coupled to multiple RADIUS servers, the RADIUS-protocol engine may be configured to select an optimal RADIUS server for authenticating clients, e.g., based on which of the RADIUS servers has the shortest latency for response.
Each protocol engine typically includes server-monitoring code for collecting and storing server statistics, and selecting optimal servers of a given protocol type. For example, server-monitoring code in the HTTP protocol engine may be configured to collect and store the network cache's HTTP-server statistics in a first table, whereas server-monitoring code in the ICAP protocol engine may collect and store the cache's ICAP-server statistics in a second table. In this case, the HTTP protocol engine consults the contents of the first table to select an optimal HTTP server, and the ICAP protocol engine references the contents of the second table to select an optimal ICAP server. More generally, in the conventional case, every software module that is configured to monitor server statistics has to periodically query each of its monitored servers and then store its obtained server statistics in a local, protocol-specific statistics table, i.e., allocated for and managed by the software module.
The above-noted conventional approach to monitoring and selecting optimal protocol-specific servers suffers various disadvantages. First, each protocol engine contains a copy of substantially the same server-monitoring code, usually differing only in terms of which particular protocol is used to collect and store the server statistics. As a result, a large amount of server-monitoring code is usually replicated among the protocol engines in the network cache. Such code replication often causes the network cache to consume excessive processing and memory resources, e.g., storing and executing multiple versions of essentially the same server-monitoring code. For example, the conventional approach may consume excessive memory resources since each protocol engine allocates and maintains a separate statistics table for storing its collected server statistics.
In addition, since the protocol engines are typically implemented at the kernel level, i.e., within the operating system of the network cache, a problem with the server-monitoring code in one protocol engine may affect operations of other kernel-level processes in the operating system. For example, a software “bug” in one protocol engine's server-monitoring code could stall, interrupt or otherwise “crash” the operating system and require the entire system to be rebooted or the operating system to be recompiled. Accordingly, it is often difficult for an administrator of the network cache to manage and debug the multiple versions of server-monitoring code executing in the kernel-level protocol engines.